Hi there, unfortunately your crate depends on a type system bug which we're going to fix in future Rust versions: rust-lang/rust#141352. We've found this crate via a crater run.

The core issue is that there are two ways to prove e.g. dyn ToJs<JsNullable<JsNumber>>: ToJs<_>:

• the builtin dyn ToJs<T>: ToJs<T> implementation for trait objects
• the user-written impl<T: ?Sized> ToJs<T> for T where T: UseInJsCode {}
  • proving the nested UseInJsCode also succeeds as UseInJsCode is a super trait of ToJs

We previously always used the builtin implementaiton to constrain _ to JsNullable<JsNumber> in here, but constraining it to dyn ToJs<JsNullable<JsNumber>> would also be valid when considering this where-bound in isolation. We will no longer prefer this builtin implementation going forward, causing this to remain ambiguous.

This causes calls to the wsdom_macros::load_ts macro to fail with ambiguity errors:

error[E0283]: type annotations needed
  --> wsdom-javascript/src/lib.rs:13:1
   |
13 | wsdom_macros::load_ts!("es5-handpicked.d.ts");
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
   |
   = note: cannot satisfy `dyn ToJs<wsdom_core::js_types::JsNullable<wsdom_core::js_types::JsNumber>>: ToJs<_>`
   = help: the following types implement trait `ToJs<JsType>`

From what I can tell this happens in

While the builtin impl does not work to create an UpcastWorkaround as constraining JsType to dyn ToJs<JsNullable<JsNumber>> results in a dyn ToJs<JsNullable<JsNumber>>: Sized bound which does not hold, this information does not get considered when checking dyn ToJs<JsNullable<JsNumber>>: ToJs<_> by itself.

I am unsure whether this is the best way to fix the breakage, but from what I can tell there are no unsized types which implement UseInJsCode 🤔